In mobile radio systems of the second and third generation, such as for instance the Global System for Mobile Communications (GSM) and the Universal Mobile Telecommunications System (UMTS), Non-Transparent (NT) data bearers are provided that offer an error-free data transfer service to the user. The data transfer service is based on the Radio Link Protocol (RLP) and the Connection-Oriented Layer-2 Relay (L2R) Protocol (COP). The RLP function offers an Automatic Repeat Request (ARQ) protocol that extends from the mobile station (MS) to the network Interworking Functions (IWF) in the Mobile-services Switching Centre (MSC) in order to detect errors by means of a Forward Error Correction (FEC) procedure and RLP's Frame Check Sequence (FCS) for each transmitted RLP frame, where an RLP frame represents an RLP Protocol Data Unit (PDU), and to eliminate errors by repeating the transmission of the frame under exploitation of the time-variance of the transmission medium. The L2R function converts the layer-2 protocol of the MS into a COP that uses transmission protected by an RLP.
The RLP is controlled by several parameters such as acknowledgement, reply and re-sequencing timers or the number of retransmission attempts or required window sizes, that either are assigned default values or can be modified by the user or network e.g. by means of AT commands. These parameters are for instance defined in Table 2 of Technical Document TS 24.022 of the Third Generation Partnership Project (3GPP). If a change of parameters is initiated in either the MS RLP entity or the MSC RLP entity, the desired parameters are signalled to the corresponding peer RLP entity via eXchange IDentification (XID) frames, which are RLP frames (PDUs) in which the information field is interpreted as exchange identification instead of data. To start negotiation, an XID command frame will be signalled. The peer entity confirms the values of the parameters by returning the value within an XID response or offering lower or higher values of the parameters in their place depending on the sense of negotiation of the parameters.
This negotiation procedure is exemplarily depicted in the signalling chart of FIG. 1a. In FIG. 1a, to establish a data transfer, an RLP entity 1 in the MS sends an XID command frame 3 with a proposed value for a parameter, in this example a proposed value for the re-sequencing timer T4, to its peer RLP entity 2 in the MSC. It should be noted that an XID command/response frame may be used for the negotiation of several parameters at a time. However, for the sake of simplicity of presentation, FIG. 1a only depicts a single parameter (the timer T4) to be negotiated. XID command/response frames may for instance further comprise an RLP version number, and/or may comprise a plurality of parameters that at least partially depend on each other. Turning back to the example of FIG. 1a, the value for the timer T4 may for instance be determined by a user of the MS via an AT command, and may be chosen as T4=60 ms. The RLP entity 2 in the MSC receives the XID command frame 3, extracts the proposed value for T4 and determines if this value is acceptable or has to be increased or decreased, depending on the sense of negotiation that is prescribed for the parameter. The accepted (T4=60 ms) or altered value (e.g. T4=80 ms as the sense of negotiation of T4 parameter allows negotiation only upwards) for the timer T4 then is returned to the MS RLP entity 1 by sending an XID response frame 4 that contains said accepted/altered value from the MSC entity 2 to the MS RLP entity 1. Further negotiation steps may take place for the parameter T4 or for other RLP parameters, until finally a data transfer 5 between the MS and the MSC can be established based on the RLP. It is understood that, prior to the start of the data transfer 5, Set Asynchronous Balanced Mode (SABM) and Unnumbered Acknowledgement (UA) frames may have to be exchanged between the peer entities 1 and 2. In FIG. 1a, this exchange is assumed to be lumped to the data transfer representation 5.
In FIG. 1b, a similar negotiation procedure is depicted. However, in contrast to the procedure of FIG. 1a, data transfer 5 is already taking place when the first XID command frame 3 with a proposal for a value of at least one parameter (e.g. the re-sequencing timer T4) is sent from the RLP entity 1 in the MS to the RLP entity 2 in the MSC, i.e. the parameter is re-negotiated during the data transfer 5. The RLP entity 2 in the MSC then either accepts or alters the proposed value for the parameter and returns the accepted/altered value within an XID response frame 4 that is returned to the RLP entity 1 of the MS. After this parameter re-negotiation, data transfer 5 can be continued based on the RLP and its re-negotiated RLP parameter. It should be noted that it is not necessarily required to interrupt the data transfer 5 for the parameter re-negotiation, re-negotiation may also take place in parallel to the data transfer 5.
In general, values for RLP parameters are limited to a respective range or alphabet that is prescribed by the RLP. For instance, the second column in table 2 of TS 24.022 defines the validity ranges for a plurality of RLP parameters. During negotiation, both the values for parameters proposed in XID command frames and the accepted/altered values in the XID response frames have to be valid values for said respective parameter, i.e. they have to lie within the validity range as defined by said RLP for each parameter. For instance, the RLP parameter P1 (dictionary size) has a validity range of 512-65535, so that a proposed value for P1 of 500 would be an invalid value.
However, due to different interpretations of RLP specifications by manufacturers of the MS and/or the MSC, or due to implementation errors, values for RLP parameters in XID command frames may be invalid, i.e. lie out of the validity ranges defined by the RLP specification. The consequence of the use of invalid values for the RLP parameters during their negotiation is usually a discarding of the received XID command frame by the entity that receives the XID frame with the invalid value, wherein either the entire XID frame (possibly containing values for a plurality of RLP parameters) or only the invalid value itself is discarded. The RLP entity that sent the XID command frame with the invalid value then most likely tries to send (re-transmit) the same XID command frame again a few times, because it does not receive an according XID response frame as acknowledgement. When the number of “maximum retransmits” is exceeded for the XID command frame, the RLP entity that tries to send the XID command frame with the invalid value for an RLP parameter may (depending on its implementation) even terminate the connection.
This scenario is depicted in FIG. 2. The RLP entity 1 in the MS sends an XID command frame 3 with an invalid value for a parameter (e.g. the re-sequencing timer T4) to its RLP peer entity 2 in the MSC. The RLP entity 2 in the MSC now detects the invalid value in the XID command frame 3 and discards the complete XID command frame 3. After the expiration of a timer that controls the time window in which a response to the XID command frame 3 has to be received, the RLP entity 1 in the MS notices that no XID response frame 4 was received from the RLP entity 2 in the MSC, and thus re-transmits the XID command frame 3 with the invalid value again, leading again to a discarding of the XID command frame 3 due to the invalidity of the value contained therein at the RLP entity 2 in the MSC. This procedure continues until a number of maximum re-transmits in the RLP entity 1 of the MS is exceeded. The RLP entity 1 in the MS then may decide to release the connection, as none of the XID commands were responded to and as no further transmissions of XID command frames are allowed.